[SPARK-59438][SQL][TESTS] Add planner-stage test coverage for ASOF JOIN sort-merge operator - #58742

…IN sort-merge operator

Adds two planner-stage tests for the ASOF JOIN sort-merge path, both
mirroring existing sibling-join test patterns:

- `PlannerSuite`: a no-equi-key `AsOfJoin` requires a single partition on
  both sides (the `AllTuples` branch of `SortMergeAsOfJoinExec`'s
  `requiredChildDistribution`), verified by running `EnsureRequirements`
  and asserting a single-partition shuffle on each side. Follows the
  existing `SortMergeJoinExec` distribution tests (SPARK-24495 /
  SPARK-27485).
- `SortMergeAsOfJoinSuite`: a null-safe (`<=>`) equi-key in `ON` is routed
  to the residual condition rather than treated as an equi-key, so null
  keys on both sides do match -- the counterpart to the existing `EqualTo`
  case where null keys never match. Mirrors `InnerJoinSuite`'s
  "inner join, null safe".

Test-only change; no production code is modified.

…l path

The null-safe (<=>) as-of test gave each left row one null candidate, so it could
not tell "keep closest" from "keep first" on the residual path. Reuse the EqualTo
sibling's data (only the ON predicate differs) and add a null-key left row at
ts=10 with two null candidates (ts=3, ts=8). The scanner must keep the closest
(ts=8), so a keep-first regression now fails.

…qui-key

The null-safe (<=>) as-of test checked only output rows, which pass whether <=>
is routed to the residual condition or treated as a null-safe equi-key. Inspect
the executed plan and assert the SortMergeAsOfJoinExec has empty equi-keys, so
the test verifies the routing its comment describes.

…n both tests

The distribution was checked only through EnsureRequirements, but the
if (leftKeys.isEmpty) AllTuples else ClusteredDistribution branch is the
behavior under test. Assert it directly: AllTuples with no equi-keys, and
ClusteredDistribution on the key with equi-keys.